Date: Wed, 26 Jan 94 10:08:41 PST 

From: Ham-Space Mailing List and Newsgroup <ham-space@ucsd.edu> 
Errors-To: Ham-Space-Errors@UCSD.Edu 

Reply-To: Ham-Space@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Space Digest V94 #10 

To: Ham-Space 


Ham-Space Digest Wed, 26 Jan 94 Volume 94 : Issue 10 


Today's Topics: 
Arsene 
Daily IPS Report - 25 Jan 94 
Low Pass filter vs Band Pass - Mode JD 
Status of polar-orbiting weather satellites 


Send Replies or notes for publication to: <Ham-Space@UCSD.Edu> 
Send subscription requests to: <Ham-Space-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Space Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-space". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 24 Jan 1994 11:45:07 GMT 

From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!torn!csd.unb.ca!upei.ca! 
UPEI.CA!seeler@network.ucsd.edu 

Subject: Arsene 

To: ham-space@ucsd.edu 


Hi - Its been a long time since I've seen anything about Arsene and was 
wondering if it has any funtions going at all at this time. 


Tnx - Dave, VY2DCS 
Internet : Seeler@upei.ca 


Date: 24 Jan 94 23:29:06 GMT 

From: swrinde!sdd.hp.com!think.com!cass.maQ2.bull.com!syd.bull.oz.au!brahman! tmx! 
basser.cs.su.oz.au!metro!news.ci.com.au!eram! dave@network.ucsd.edu 

Subject: Daily IPS Report - 25 Jan 94 

To: ham-space@ucsd.edu 


IPS RADIO AND SPACE SERVICES AUSTRALIA 

Daily Solar And Geophysical Report 

Issued at 2330 UT 24 January 1994 

Summary for 24 January and Forecast up to 27 January 

IPS Warning 02 was issued at 24/2200UT January and is current 
for period January 27 - 29. 


1A. SOLAR SUMMARY 
Activity: low 


Flares: none. 
Observed 10.7 cm flux/Equivalent Sunspot Number : 129/082 


1B. SOLAR FORECAST 


25 January 26 January 27 January 
Activity Low Low Low 
Fadeouts None expected None expected None expected 


Forecast 10.7 cm flux/Equivalent Sunspot Number : 130/084 


1C. SOLAR COMMENT 
None. 


2A. MAGNETIC SUMMARY 
Geomagnetic field at Learmonth : quiet 


Estimated Indices : A K Observed A Index 23 January 
Learmonth 02 2111 0001 
Fredericksburg 02 07 
Planetary 04 05 


2B. MAGNETIC FORECAST 

DATE Ap CONDITIONS 

25 Jan 08 Quiet to unsettled. 
26 Jan 08 Quiet to unsettled. 
27 Jan 20 Unsettled to active. 


2C. MAGNETIC COMMENT 
Active periods expected during interval 27-29 Jan due to coronal 
hole. 


3A. GLOBAL HF PROPAGATION SUMMARY 
LATITUDE BAND 


DATE LOW MIDDLE HIGH 
24 Jan normal normal normal 
PCA Event : None. 
3B. GLOBAL HF PROPAGATION FORECAST 

LATITUDE BAND 


DATE LOW MIDDLE HIGH 
25 Jan normal normal fair 
26 Jan normal normal fair 
27 Jan normal fair poor 


3C. GLOBAL HF PROPAGATION COMMENT 
Degraded comms expected at mid/high lats during interval 
27-29 January. 


4A. AUSTRALIAN REGION IONOSPHERIC SUMMARY 
MUFs at Sydney were about 15% above predicted monthly values 


T index: 73 


4B. AUSTRALIAN REGION IONOSPHERIC FORECAST 

DATE T-index MUFs 

25 Jan 75 About 15% above predicted monthly values. 
26 Jan 75 About 15% above predicted monthly values. 
27 Jan 75 About 15% above predicted monthly values. 


Predicted Monthly T Index for January is 30. 


4C. AUSTRALIAN REGION COMMENT 
Degraded HF comms expected during Jan 27-29. 


Dave Horsfall (VK2KFU) VK2KFU @ VK20P.NSW.AUS.OC PGP 2.3 
dave@esi.COM.AU ...munnari!esi.COM.AU! dave available 


Date: Mon, 24 Jan 1994 11:53:17 GMT 

From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!torn!csd.unb.ca!upei.ca! 
UPEI.CA!seeler@network.ucsd.edu 

Subject: Low Pass filter vs Band Pass - Mode JD 

To: ham-space@ucsd.edu 


I have some desensing of my 440 rig on receive when the 2 meter rig fires 
up on Mode JD. This is not a MAJOR problem but I would like to resolve it. 
I suspect that it involves the 3rd harmonic of the 2 meter Transmitter. 


The books suggest using a low pass or band pass filter - but they differ as 
to which would be best ( opinion or operation differences?). I use the all 


IC275 for Dx and local operations as well and suspect that the low pass 
filter would be a good start. The filter in the VHF/UHF Dx book appears 
to fit my needs - 35? db attenuation of the 2nd harmonic and 60 db 
attenuation of the 3rd - with minimal (?) insertion loss. 


My questio is this - is the low pass filter the best way to solve this 
particular issue - and if so - does anyone have any suggestions as to 

any particular filter design / schematics - and comments as to how they/it 
works? 


Thanks for considering this post. 


Dave, VY2DCS 
Internet: Seeler@upei.ca 


Date: Tue, 25 Jan 94 17:46:00 +0200 

From: swrinde!cs.utexas.edu! howland.reston.ans.net!pipex!uknet!EU.net! 
news.eunet. fi! gate.compart.£1i! compart! leo.wikholm@network.ucsd.edu 
Subject: Status of polar-orbiting weather satellites 

To: ham-space@ucsd.edu 


STATUS OF POLAR-ORBITING WEATHER SATELLITES 


No. 2, January 25, 1994 
Station: Helsinki, +60.2N +25.1E 


NOAA 9 137,62 MHz normal 
NOAA 10 137,50 MHz VHF conflict with NOAA 12? 
NOAA 11 137,62 MHz normal 
NOAA 12 137,50 MHz normal 


Meteor 3-5 137,30 MHz not actice in North 
Meteor 2-21 137,30 MHz not active in North 


Leo Wikholm 
internet: leo.wikholm@compart. fi 
fidonet : 2:220/861 


Date: 24 Jan 94 09:24:44 -0700 

From: ucsnews!newshub.sdsu.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com! 
news.umbc.edu!eff£!news.kei.com!sol.ctr.columbia.edu!hamblin.math.byu.edu! 
yvax.byu.edu!physc1.byu.edu! peterson@ 

To: ham-space@ucsd.edu 


References <2hd6ji$q5e@hpavla.l£.hp.com>, 
<1994Jan17 .145311.25166@ke4zv.atl.ga.us>, <CKOE5n.LG9@world.std.com>tr.colu 
Subject : Re: Vacuum tubes in spacecraft? 


In article <CKOE5n.LG9@world.std.com>, dts@world.std.com (Daniel T Senie) writes: 
> In article <1994Jan17.145311.25166@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary 
Coffman) writes: 

>>Note also that program bloat can be traced almost completely to having 
>>excess RAM available. Programs naturally expand to fill the space available, 
>>witness Wordstar. It was a great fast program on a 48 kb Z-80 system, but 


common misconception. Wordstar NEVER fit in 48K. Sure it would run ina 
machine that had 48K, but every time you hit “Y to delete a line, it 
had to swap in an overlay from disk to do the function, then swap back 
to the main code. When more memory is available, it is possible to 
improve performance. 


VV VVV VV 


>>now it's a multi-megabyte dog on a Windows PC with 8+ megs of RAM. And 
>>that's 166 times more RAM to develop a bit error that can crash the system. 
>>To a large degree, reliability is a function of parts count. The fewer 
>>parts, the less to go wrong. 

>> 

> 

> Actually in software the less is better philosopy does not always hold. To 

> get program size smaller, one could always skip the bounds checking and input 
> parameter checking. Fewer parts, but less reliability... 


>>Gary Coffman KE4ZV | You make it, | gatech!wa4mei! ke4zv! gary 
> 

> -= 

> wee ee ee ee ee ew ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee eee ee ee ee eee eee 

> Daniel Senie Internet: dts@world.std.com 

> Daniel Senie Consulting nijeb@world.std.com 

> 508-365-5352 Compuserve: 74176 ,1347 


Actually there are two other driving forces in the software bloat that are only 
allowed to operate because of the cheap RAM: 1) The demand for software that 
requires no thought or training. Some of this is good and some of it is 
useless "creeping featurism" (I have yet to understand why a top quality word 
processing package would require you to remove your hands from the keyboard to 
perform basic formatting functions). And 2) the trend toward using high-level 
languages for all software development. Most of those "lean and mean" packages 
of the past were written in optimized assembly code because RAM was tight. Now 
they don't have to put any effort into optimizing the code and are able to 
write using high-level languages and compilers that generate absolutely 


horrendous code (from an efficiency standpoint). Yes, that allows them to meet 
the demands of (1) above more quickly but at a tremondous cost in storage space 
(just for grins look at the bloat in the distribution disks for ANY package 
over the last few years - things that used to be delivered on 2 360K floppies 
now require 4 to 6 1.44M floppies and add data compression to boot). Whether 
this whole trend is good or bad is a totally religious argument (hardware is 
cheap and features are nice versus why do I need so much hardware just to run 

a simple application). 


However, any way you look at it my hat goes off to the programmers who are able 
to fit the entire control program for the Shuttle into the memory on those 
computers. I can guarantee they are not using the bloated high-level languages 
that you normally see in the PC world to do that. 


Bryan Peterson, ki7td 
peterson@physci1.byu.edu 


End of Ham-Space Digest V94 #10 
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